Virtual ldp session

ABSTRACT

A receiving node receives a virtual LDP initialization (vInit) message from a first node, where the vinit message comprises a request to establish a vLDP session between a requesting node and a target node. If the receiving node does not own a destination address of the vinit message, the receiving node is determined to be a relay node. The relay node inserts a relay label into the vinit message, where the relay label is an outgoing label that the relay node uses to reach the first node, and forwards the vinit message toward the destination address. If the receiving node owns the destination address, the receiving node is determined to be the target node, which extracts a stack of relay labels from the vinit message. The relay labels are used to define a return path to the requesting node for messages transmitted over the vLDP session.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present patent application is a continuation of U.S. patentapplication Ser. No. 15/663,898 filed on Jul. 31, 2017, entitled“Virtual LDP Session”; which is a continuation of U.S. patentapplication Ser. No. 14/040,989 filed on Sep. 30, 2013, which issued asU.S. Pat. No. 9,769,068 on Sep. 19, 2017, entitled “Virtual LDPSession.” All are incorporated by reference herein in its entirety andfor all purposes as if completely and fully set forth herein.

TECHNICAL FIELD

The present disclosure relates generally to MPLS (multiprotocol labelswitching) protocols and, more particularly, to establishing a virtualLDP session between nodes that do not have IP (Internet Protocol)reachability.

BACKGROUND

Businesses employ networks to interconnect their computers, servers,storage devices, and other network elements. As a business grows, so canits network, increasing the number of network elements coupled to thenetwork, the number of network links, and also geographic diversity. Abusiness' network elements can be scattered throughout a city, a state,a country, or the world. Many businesses establish connectivity betweennetwork elements at disparate geographic sites using variousintermediate networked areas or domains, such as a third partyprovider's network. Transmission paths may be established through thevarious intermediate networked domains using different communicationprotocols. Depending on the communication protocols implemented insideand outside of the networked domains, some routing information may notbe available at a given network node.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present disclosure may be acquiredby referring to the following description and accompanying drawings, inwhich like references numbers indicate like features.

FIG. 1 is a block diagram illustrating components of an example networkin which the present disclosure can be implemented, according to oneembodiment.

FIG. 2 is a block diagram illustrating components of an example virtualLDP (vLDP) logic module in which the present disclosure can beimplemented, according to one embodiment.

FIG. 3A is a block diagram illustrating components of an example virtualLDP initialization (vinit) message, according to one embodiment.

FIG. 3B is a block diagram illustrating components of an exampletransmission path of a vinit message from a requesting node to a targetnode via two relay nodes, according to one embodiment.

FIG. 4 is a block diagram illustrating components of an example vLDPmessage, according to one embodiment.

FIGS. 5A and 5B are flowcharts illustrating operations of an examplevLDP session establishment process, according to one embodiment.

FIG. 5C is a flowchart illustrating operations of an example vLDPmessage exchange process using a vLDP session, according to oneembodiment.

FIG. 6 is a block diagram illustrating components of another examplenetwork in which the present disclosure can be implemented, according toone embodiment.

FIGS. 7A and 7B are flowcharts illustrating operations of an examplemLDP node protection process implementing the present disclosure,according to one embodiment.

FIG. 8 is a block diagram illustrating components of an example networkdevice in which the present disclosure can be implemented, according toone embodiment.

FIG. 9 is a block diagram illustrating components of an example networkdevice in which the present disclosure can be implemented, according toone embodiment.

While the present disclosure is susceptible to various modifications andalternative forms, specific embodiments of the present disclosure areprovided as examples in the drawings and detailed description. It shouldbe understood that the drawings and detailed description are notintended to limit the present disclosure to the particular formdisclosed. Instead, the intention is to cover all modifications,equivalents and alternative falling within the spirit and scope of thepresent disclosure as defined by the appended claims.

DETAILED DESCRIPTION Overview

A receiving node receives a virtual LDP initialization (vinit) messagefrom a first node, where the vinit message comprises a request toestablish a vLDP session between a requesting node and a target node. Ifthe receiving node does not own a destination address of the vinitmessage, the receiving node is determined to be a relay node. The relaynode inserts a relay label into the vinit message, where the relay labelis an outgoing label that the relay node uses to reach the first node,and forwards the vinit message toward the destination address. If thereceiving node owns the destination address, the receiving node isdetermined to be the target node, which extracts a stack of relay labelsfrom the vinit message. The relay labels are used to define a returnpath to the requesting node for messages transmitted over the vLDPsession.

Example Embodiments

FIG. 1 is a block diagram illustrating components of an example network100 in which the present disclosure can be implemented. Network 100includes a number of network segments 110(1)-(N) that implement MPLS(multiprotocol label switching) and a number of label switching routingelements 120(1)-(N). Network 100 can also implement Inter-AS (AutonomousSystem) VPN (Virtual Private Network) and Seamless/Unified MPLS.Examples of a network segment 110 include an autonomous system (AS), acustomer network, a service provider network, a customer carriernetwork, a backbone network, a transport network, a core network, anetwork, a sub-network, an aggregate domain, a core domain, an accessdomain, a networked area, and/or a routing domain.

Each network segment includes a set of label switching routing elements120 (also referred to as LSRs or nodes). Each LSR 120 is configured toimplement a routing protocol (e.g., an interior routing protocol, suchas IGP (Interior Gateway Protocol), OSPF (Open Shortest Path First),IS-IS (Intermediate System to Intermediate System), EIGRP (EnhancedInterior Gateway Routing Protocol), and the like). Each LSR 120 isconfigured to exchange routing information with other LSRs within thesame network segment and store the routing information in a local IP(Internet Protocol) routing table, which includes routes to variousdestinations in the network segment (also referred to as routes interiorto a network segment, or more simply as interior routes). A destinationwith a route stored in the local IP routing table is referred to asbeing IP (or unicast) reachable (e.g., the known route reaches thedestination). As illustrated, LSR 120(1) is located in network segment110(1) and exchanges routing information with other LSRs within networksegment 110(1), and LSR 120(N) is located in network segment 110(N) andexchanges routing information with other LSRs within network segment110(N). However, LSRs within a network segment will likely not have anyrouting information for a destination outside of the network segment.Such an outside destination is referred to as being IP (or unicast)unreachable (e.g., there is no known route stored in the local IProuting table that reaches the outside destination). For example, LSR120(1) is IP unreachable for LSR 120(N). In other words, the IP addressof LSR 120(1) is private to network segment 110(1) since the route tosuch an IP address is not distributed outside of network segment 110(1).Similarly, LSR 120(N) is IP unreachable for LSR 120(1). Since LSR 120(1)and LSR 120(N) are IP unreachable (e.g., do not have routes to oneanother), LSRs 120(1) and 120(N) do not have IP connectivity with oneanother.

Network segments 110(1)-(N) are coupled via a number of border LSRs andedge LSRs. As illustrated, border LSR 130 is connected to edge LSR120(1) of network segment 110(1) and to edge LSR 120(N) of networksegment 110(N). An example border LSR 130 is an area border router (orABR, such as in a Seamless/Unified MPLS) and an autonomous systemboundary router (ASBR, such as in an Inter-AS scenario). Edge LSRs arelocated at the edge of a network segment. Border LSRs and edge LSRs areconfigured to implement a routing protocol (as discussed above) and areachability protocol (e.g., an exterior routing protocol or networkreachability protocol, such as BGP (Border Gateway Protocol, alsoreferred to as eBGP (exterior BGP)), and the like). Each BGP peer (e.g.,border LSRs and edge LSRs in network 100) is configured to exchangereachability information with other BGP peers. A border LSR and/or edgeLSR is configured to store the reachability information (e.g., in alocal BGP routing table and/or IP routing table), which includes routesto the various network segments in the network (also referred to asroutes exterior to a network segment, or more simply as exteriorroutes). The exterior routes to the various network segments are sharedwith other BGP peers, while the core LSRs (or LSRs located within theinterior of a network segment) do not receive such exterior routes.

A label switched path (LSP) can be established in network 100, which isdefined by a set of labels. Labels are short, fixed length, locallysignificant identifiers that are used to identify a ForwardingEquivalence Class (FEC). An FEC represents packets that share a samerequirement for transport (e.g., over the same path with the sameforwarding treatment). Each LSP is associated with at least one FEC thatspecifies which packets are mapped to that LSP. In order to build anLSP, each LSR is configured to exchange labels with one another using alabel distribution protocol, such as LDP (Label Distribution Protocol)and/or multipoint extension to LDP (mLDP). The LDP protocol logic isillustrated as LDP logic module 140, implemented on LSRs 120(1)-(N) andborder LSR 130. A given LSR binds a label to each destination in theLSR's local routing tables, and distributes this label binding to itspeers (e.g., labels for interior routes are exchanged among LSRs (suchas LDP peers) in the same network segment and labels for exterior routesare exchanged with edge LSRs and border LSRs (such as BGP peers) of oneor more network segments). Each LSR stores the labels in a labelinformation base (LIB) and/or a label forwarding information base (LFIB)and uses the labels to forward (or label switch) a packet along an LSPtoward the packet's destination.

A pair of directly connected LSRs (e.g., one LSR is one hop away fromthe other LSR, also referred to as a next hop neighbor) can establish anLDP session to exchange labels with one another. The pair of LSRs (orend nodes) establishes an underlying TCP (Transmission Control Protocol)connection, which is used to set up the LDP session (e.g., negotiate LDPsession parameters). The LDP session runs over the TCP connection. Toestablish the TCP connection, the pair of LSRs must have IP connectivitywith one another (or each LSR has a route to the IP address for theother LSR). As illustrated, LSR 120(1) and border LSR 130 have IPconnectivity with each other and have established a TCP connection145(1), over which an LDP session can be established. Similarly, LSR120(N) and border LSR 130 also have IP connectivity with each other andhave established another TCP connection 145(2), over which another LDPsession can be established.

A pair of LSRs (or end nodes) that are not directly connected (e.g., oneLSR is more than one hop away from the other LSR, also referred to as aremote neighbor) can establish a targeted LDP session to exchange labelswith one another. A targeted LDP session also runs over a TCP connectionbetween the pair of LSRs. To establish a targeted LDP session, the pairof LSRs must also have IP connectivity with one another (e.g., in orderto establish a TCP connection from one LSR to the other LSR). Asillustrated, LSR 120(1) and LSR 120(N) do not have IP connectivity toone another because LSR 120(1) and LSR 120(N) are located in differentnetwork segments 110 that have limited routing information (e.g., LSR120(1) does not have a route to LSR 120(N), and LSR 120(N) does not havea route to LSR 120(1)). Without IP connectivity, a TCP connection (andthus a targeted LDP session) cannot be established between LSR 120(1)and LSR 120(N). Additionally, there is no existing LSP that connects LSR120(1) and LSR 120(N).

The present disclosure provides for a virtual LDP session that can beset up between a pair of edge LSRs that are not directly connected(e.g., that are remotely located from one another) and do not have IPconnectivity with one another. As discussed above, TCP connections areestablished by LDP protocol logic while setting up LDP sessions with LDPneighbors. The present disclosure provides a lightweight extension toLDP protocol logic to establish a virtual LDP (vLDP) session over theexisting TCP connections that couple the pair of edge LSRs via one ormore relay nodes. Once established, the edge LSRs treat the vLDP sessionas a normal LDP session and each edge LSR treats the other edge LSR as anormal LDP neighbor (e.g., each LSR views the other edge LSR as if theother edge LSR were directly connected). Thus, the vLDP session providesa virtual LDP neighborship between the pair of edge LSRs, where LDPmessages can be encapsulated or otherwise identified as vLDP messages,exchanged over the vLDP session, decapsulated, and processed by LDPprotocol logic. A vLDP session can be used in unicast and multicastimplementations.

Using the example illustrated in FIG. 1, a vLDP session 155 isestablished from first edge LSR 120(1) to second edge LSR 120(N) overexisting TCP connections 145(1) and 145(2). In other words, a direct TCPconnection from LSR 120(1) to LSR 120(N) can be “stitched” together atone or more relay nodes (e.g., border LSR 130), over which a vLDPsession can be established. In one embodiment, while LDP state (e.g.,FEC state, LDP bindings, and/or mLDP forwarding state) is maintained atthe pair of edge LSRs, the one or more relay nodes need not store LDPstate. In another embodiment, some reliability state can be maintainedat the one or more relay nodes when an end-to-end reliability feature isimplemented (further discussed below in connection with FIG. 4). LDPprotocol logic is illustrated as LDP logic module 140 and vLDP extensionto LDP protocol logic is illustrated as vLDP logic module 150. Thesecomponents are further discussed below in connection with FIG. 2.

The present disclosure also provides for a virtual LDP initialization(vinit) message that is forwarded across the one or more relay nodes tocollect one or more relay labels, which are used to label switch vLDPmessages from one edge LSR to the other edge LSR. The one or more relaynodes act as passthrough nodes, without needing to store anyLSP-specific information (e.g., need not store LDP state) at the one ormore relay nodes. A vLDP session is especially helpful in mLDP nodeprotection when a targeted LDP session cannot be established between theMerge Point (MPT) and Point of Local Repair (PLR), as further discussedbelow in connection with FIG. 6. While a vLDP session can be implementedto replace a targeted LDP, a vLDP session can (optionally) beestablished over a targeted LDP session, as further discussed below inconnection with FIG. 4.

The vLDP session leverages existing security features implemented by theexisting TCP connections as vLDP messages are conveyed over the existingTCP connections. Thus, label mapping messages can be exchanged over thevLDP session in a reliable and secured manner between nodes that do nothave reachability. The vLDP session also provides a mechanism toexchange labels between nodes in different network segments withoutneeding to leak reachability information (where such leaking wouldrequire very careful design that may not be scalable, or may destroy theintention of unified/seamless MPLS).

Network 100 can utilize Ethernet, IEEE 802.11x, or some othercommunications protocol. In light of the present disclosure, it will beappreciated that network 100 can include other components such asrouters, firewalls and the like that are not germane to the discussionof the present disclosure and will not be discussed further herein. Itwill also be appreciated that other configurations are possible. Forexample, a much larger number of network segments 110(1)-(N), and/orLSRs 120(1)-(N) than the number shown can be implemented in the network,and so on.

The letter N is used to indicate a variable number of devices orcomponents. For example, a variable number of network segments110(1)-(N) and LSRs 120(1)-(N) are implemented in the network. Althoughthe letter N is used in describing a variable number of instances ofeach of these different devices and components, a repeated use of theletter N does not necessarily indicate that each device and componenthas a same number of N instances implemented in the network.

FIG. 2 is a block diagram illustrating components of an example virtualLDP (vLDP) logic module 150 in which the present disclosure can beimplemented. vLDP logic module 150 is configured to be implemented on anLSR or node (e.g., LSR 120 or border LSR 130) and is configured tocommunicate with an existing LDP logic module 140 that is alsoimplemented on the node. vLDP logic module 150 includes an IPunreachability detector 205, a virtual LDP initialization (vInit)message generator 210, a vinit message processor 220, a vLDP messagegenerator 240, and vLDP message processor 250. vinit message processor220 also includes a relay label insertor 230 and a relay label extractor235. Each component is further discussed below.

IP unreachability detector 205 is configured to discover a target nodeand detect if the target node is IP unreachable. In other words, IPunreachability detector 205 is configured to determine that a targetedLDP session cannot be established between the node (acting as arequesting node) and the target node.

IP unreachability detector 205 is configured to use a discoverymechanism to discover the target node's address (and thus also discoverthe target node). For example, IP unreachability detector can receivethe address of the target node from a directly connected node (e.g.,from a relay node, such as a protected node during mLDP node protection,as further discussed below in connection with FIG. 6), or the address ofthe target node can be manually configured at the requesting node. IPunreachability detector can consult an IP routing table at therequesting node and determine that the address of the target node is IPunreachable (e.g., determine whether the requesting node has a knownroute for the target node's address).

IP unreachability detector 205 is also configured to use a discoverymechanism to discover one or more relay nodes. For example, IPunreachability detector can discover directly connected relay nodeswhile the requesting node exchanges LDP hello messages with otherdirectly connected nodes. Also, IP unreachability detector 205 can beconfigured to consult a BGP table and/or other routing tables at therequesting node to determine an access point (e.g., a border LSR) thatreaches the target node (e.g., be IP reachable with the target node)and/or to determine a directly connected IP reachable relay node that isthe next hop toward the target node (or access point). Additionally, anaddress of a relay node can be manually configured at the requestingnode.

vinit message generator 210 is configured to generate a virtual LDPinitialization (vinit) message and transmit the vinit message toward adestination, such as a target node. An example vinit message is furtherdiscussed in connection with FIG. 3A, where the vinit message is used togather labels during initialization of the vLDP session. An exampletransmission path of a vinit message is further discussed in connectionwith FIG. 3B. In one embodiment, a vinit message is a newly definedinitialization message. In another embodiment, a vinit message is an LDPinitialization message that is identified as a vinit message, where theLDP initialization message includes optional vinit parameters. The LDPinitialization message that is identified as a vinit message is definedby LDP protocol logic.

vinit message processor 220 is configured to receive and process a vinitmessage. vinit message process also includes a relay label insertor 230that is configured to insert a relay label into a received vinitmessage, and a relay label extractor 235 that is configured to extract arelay label from a received vinit message. If the node (on which vinitmessage processor 220 is implemented) acts as a relay node, vinitmessage processor 220 is configured to forward a received vinit message(after inserting a label into the vinit message) toward the target node.If the node (on which vinit message processor 220 is implemented) actsas the target node, vinit message processor 220 is configured toinstruct vinit message generator 210 to generate a responsive vinitmessage and to transmit the responsive vinit message back towards therequesting node. Example transmission paths of vinit messages between arequesting node and target node is further discussed in connection withFIG. 3B.

vLDP message generator 240 is configured to generate a virtual LDP(vLDP) message, impose one or more labels on the vLDP message (which aregathered during initialization of the vLDP session, as further discussedbelow in connection with FIG. 3A), and transmit the vLDP message to itsdestination (or label-switch the vLDP across a “stitched” point-to-pointLSP between the requesting node and the target node, which is defined bythe one or more labels imposed on the vLDP message). In one embodiment,a vLDP message includes an LDP message, where the LDP message isencapsulated in a vLDP message. In another embodiment, a vLDP message isan LDP message that is identified as a vLDP message, where the LDPmessage includes optional vLDP parameters. The LDP messages that areencapsulated or otherwise identified as vLDP messages are defined by LDPprotocol logic. An example of a vLDP message is further discussed belowin connection with FIG. 4.

vLDP message processor 250 is configured to receive and process a vLDPmessage. In one embodiment, vLDP message processor 250 decapsulates areceived vLDP message to reveal the LDP message. In another embodiment,vLDP message processor 250 determines that a received message isidentified as a vLDP message. vLDP message processor 250 is alsoconfigured to process a received vLDP message cooperatively with LDPprotocol logic (e.g., can provide the decapsulated LDP message to LDPlogic module 140 or uses existing logic present in LDP logic module toprocess the received vLDP message).

FIG. 3A is a block diagram illustrating components of an example virtualLDP initialization (vinit) message. vinit message 300 is generated byvinit message generator 210 of vLDP logic module 150, where vinitmessage 300 can be originated by an edge LSR on which vLDP logic module150 is implemented. A vinit message is sent from a requesting node to atarget node to request that a vLDP session be established between therequesting node and the target node. A vinit message is forwarded over anumber of existing TCP connections via one or more relay nodes betweenthe requesting node and the target node. The TCP connections may havebeen previously established while the requesting node, target node, andone or more relay nodes established LDP sessions with their directlyconnected LDP neighbors. A vinit message is also sent in response fromthe target node to the requesting node to confirm that the request toestablish a vLDP session is accepted.

The format of vinit message 300 includes an LDP ID (identifier) 305, asession ID (identifier) 310, one or more relay labels 320, a sourceaddress 330, and a destination address 340. In another embodiment,session ID 310, relay label(s) 320, source address 330, and destinationaddress 340 can be defined as optional parameters of a (traditional) LDPinitialization message, where an LDP initialization message with theseoptional parameters is a vinit message. Each component is furtherdiscussed below.

LDP ID 305 is a piece of data (often a six-byte quantity) thatidentifies the label space of the originating node, as defined by LDPprotocol logic. For example, if vinit message 300 were originated by arequesting node, the vinit message would include the LDP ID of therequesting node. Session ID 310 is a piece of data (such as a hashvalue, random number, and/or random string) generated to identify a vLDPsession between a pair of LSRs, or between a requesting node and atarget node. Source address 330 is the IP address of the requesting nodethat generates the vinit message. Destination address 340 is the IPaddress of the target node to which the vinit message will be sent.Using the example illustrated in FIG. 1, source address 330 is the IPaddress of requesting node LSR 120(1) that wishes to establish a vLDPsession with target node LSR 120(N), and destination address 340 is theIP address of target node LSR 120(N).

It is noted that when vinit message 300 is initially generated by therequesting node, vinit message 300 will not include a relay label 320.The requesting node sends vinit message 300 toward the target node viaone or more relay nodes. When a (first) relay node (such as border LSR130 in FIG. 1) receives vinit message 300 from the requesting node, therelay node determines that it does not own destination address 340 andthat vinit message 300 indicates a vLDP session is being established. Inresponse, the relay node adds the label that the requesting nodeadvertised to the relay node (e.g., the outgoing label that the relaynode uses to reach the requesting node) as a new relay label 320 tovinit message. The relay node then forwards vinit message toward thetarget node (that is identified in destination address 340). Using theexample illustrated in FIG. 1, the vinit message is forwarded by asingle relay node, border LSR 130, to target node LSR 120(N). Receipt ofthe vinit message at the target node is further discussed below inconnection with FIG. 3B.

FIG. 3B is a block diagram illustrating components of an exampletransmission path of a vinit message from a requesting node 350(1) to atarget node 350(2) via two relay nodes 355(1) and 355(2). Although onlytwo relay nodes are illustrated, more than two relay nodes could belocated between requesting node 350(1) and target node 350(2). It isnoted that each relay node must also have an existing TCP connectionwith its neighboring node (e.g., have IP connectivity with a next hoprelay node) in order for the vLDP session to be established across therelay nodes. As illustrated, TCP connections 360(1), 360(2), and 360(3)respectively couple nodes 350(1), 355(1), 355(2), and 350(2). The TCPconnections may have been previously established when the requestingnode, target node, and one or more relay nodes established various LDPsessions with their directly connected LDP neighbors. Thus, the one ormore relay nodes are also LDP neighbors and an LDP session may also berunning over each of TCP connections 360(1)-(3).

As illustrated, vinit message 300 is sent from requesting node 350(1) toa (first) relay node 355(1), as discussed above in connection with FIG.3A. vinit message is then forwarded from relay node 355(1) to the nextrelay node 355(2) toward the target node over TCP connection 360(2). Inother words, receiving relay node 355(2) receives vinit message fromforwarding relay node 355(1). Receiving relay node 355(2) determinesthat it does not own destination address 340 and that the vinit messageindicates a vLDP session is being established. In response, receivingrelay node 355(2) adds the label that forwarding relay node 355(1)advertised to receiving relay node 355(2) (e.g., the outgoing label thatthe receiving relay node uses to reach the forwarding relay node) as anew relay label 320 to vinit message 300. Receiving relay node 355(2)adds the new relay label to vinit message by pushing the new relay labelon top of a stack of existing relay label(s) included in vinit message(also referred to as a relay label stack). The most-recently added relaylabel is the top or outer label of the relay label stack, while theoldest added relay label (e.g., the label added by the relay node thatfirst received vinit message from the requesting node) is the bottom orinner label of the relay label stack. Receiving relay node 355(2) thenforwards the vinit message toward the target node (that is identified indestination address 340). This process repeats at the next relay node(if any) that receives the vinit message. A stack of one or more relaylabels is collected in the vinit message, as the vinit message isforwarded toward the target node.

Once target node 350(2) receives vinit message 300 from a (terminal orfinal) relay node (where the vinit message has been forwarded by asingle relay node or by more than one relay node), target node 350(2)determines that it owns destination address 340 and that vinit message300 indicates a vLDP session is being established. In response, thetarget node extracts the stack of one or more relay labels 320 from thereceived vinit message and stores the stack of relay labels (e.g., in anLFIB table). The target node may also push an outer label on top of thestored stack of relay labels, where the outer label is advertised by theterminal relay node to the target node (e.g., the outgoing label thatthe target node uses to reach the terminal relay node). The target nodealso associates the (stored) relay labels and outer label with thesession ID 310 of the vLDP session and/or the LDP ID of the requestingnode (which are included in the received vinit message). The stack ofrelay labels, including the outer label, defines a return path (e.g., astitched point-to-point LSP) from the target node back to the requestingnode, along the same path followed by the vinit message from therequesting node to the target node.

The target node also generates a responsive vinit message to send backto the requesting node. The responsive vinit message includes the samesession ID 310 of the received vinit message to indicate confirmationthat the request to establish a vLDP session is accepted. The responsivevinit message also includes source address 330 of the target node,destination address 340 of the requesting node, and LDP ID of the targetnode. In one embodiment, target node 350(2) can use the stack of relaylabel(s) 320 to label-switch the responsive vinit message directly backto requesting node 350(1).

In another embodiment, the responsive vinit message is forwarded towardrequesting node 350(1) and collects a second stack of one or more relaylabels 320, as discussed above. The requesting node extracts and storesthe second stack of relay labels (e.g., in an LFIB table), and pushes anouter label on the second stack of relay labels, where the outer labelis an outgoing label that reaches the relay node from which theresponsive vinit message is received. The requesting node associates the(stored) relay labels and outer label with the session ID of the vLDPsession and/or the LDP ID of the target node (which are included in theresponsive vinit message). The second stack of relay labels, includingthe outgoing label, defines a return path (e.g., a stitchedpoint-to-point LSP) from the requesting node back to the target node,along the same path followed by the responsive vinit message from thetarget node to the requesting node. The vLDP session is established whenthe requesting node receives the responsive vinit message.

Thus, in one embodiment, the LFIB of the requesting node may include thefollowing entry illustrated in Table A (where the label stack to reachthe target node may include an additional relay label for eachadditional relay node located between the requesting node and the targetnode):

TABLE A Address of Session LDP ID of Label Stack to reach Target Node:Target Node ID Target Node Outer Label (Requesting Node to Relay Node)Return Label (Relay Node to Target Node)

The LFIB of the target node may include the following entry illustratedin Table B (where the label stack to reach the requesting node mayinclude an additional relay label for each additional relay node locatedbetween the requesting node and the target node):

TABLE B Address of Session LDP ID of Label Stack to reach RequestingNode: Requesting ID Requesting Outer Label (Target Node Node Node toRelay Node) Relay Label (Relay Node to Requesting Node)

FIG. 4 is a block diagram illustrating components of an example vLDPmessage 400. Once the vLDP session is established between the requestingnode and the target node, vLDP messages can be exchanged between therequesting node and the target node over the TCP connections using therelay label stack and outer label collected during initialization of thevLDP session. In other words, one end node can send message over astitched point-to-point LSP to the destination end node by imposing therelay label stack and outer label on the message and label-switching themessage to the destination end node.

vLDP message 400 includes an LDP ID (identifier) 410, a session ID(identifier) 310, and a (traditional) LDP message 420. In anotherembodiment, LDP ID 410 and session ID 310 can be defined as optionalparameters of a (traditional) LDP message, where an LDP message withthese optional parameters is a vLDP message. Each component is furtherdiscussed below.

LDP ID 410 is a piece of data (often a six-byte quantity) thatidentifies the label space of the destination end node, which waspreviously included in the vinit message used to establish the vLDPsession. Session ID 310 is a piece of data that identifies the vLDPsession established between the requesting and target nodes, which waspreviously included in the vinit message used to establish the vLDPsession. In one embodiment, each vLDP session can be uniquely identifiedby a combination of the LDP ID and session ID. For example, a targetnode that has the entry illustrated above in Table B would retrieve theLDP ID of the requesting node from the LFIB table entry (and the sessionID of the vLDP session established between the target node and therequesting node) for inclusion in the vLDP message to the requestingnode. LDP message 420 is a (traditional) LDP message used forcommunication between the pair of nodes (e.g., a label mapping message,a notification message, and the like), as defined by LDP protocol logic.

The requesting node and the target node use their respective stacks ofone or more relay labels 320 (included in the vinit message received bythe requesting node or target node) to communicate with one another byimposing the respective stack of relay labels 320 on a vLDP message sentto the other node. The requesting node and the target node also imposean outer label 430 that is used (by the requesting node or the targetnode) to reach the terminal relay node (e.g., the (final) relay nodefrom which the vinit message was received). The respective stacks andouter labels are also illustrated above in Tables A and B.

Using the example scenario illustrated in FIG. 3B, target node 350(2)receives a stack of one or more relay labels 320 in a vinit message.Target node 350(2) imposes stack of relay label(s) 320 in the samesequence or order on a vLDP message 400 that is being sent to requestingnode 350(1). Target node 350(2) also imposes the outgoing label thattarget node 350(2) uses to reach relay node 355(2) as outer label 430.vLDP message 400 can then be label-switched back to the requesting nodeusing outer label 430 and relay label(s) 320, despite the lack of IPconnectivity between the requesting node and the target node.

Continuing the example scenario illustrated in FIG. 3B, requesting node350(1) receives a second stack of one or more relay labels 320 in aresponsive vinit message. Requesting node 350(1) imposes relay label(s)320 in the same sequence or order on a vLDP message 400 that is beingsent to target node 350(2). Requesting node 350(1) also imposes theoutgoing label that requesting node 350(1) uses to reach relay node355(1) as outer label 430. vLDP message 400 is label-switched back totarget node 350(2) using the outer label and second stack of relaylabel(s) 320.

When a vLDP message is received by a requesting node or target node, therequesting node or target node processes the LDP message included in thevLDP message using (traditional) LDP protocol logic. In one embodiment,if a label mapping message is received at an end node (e.g., requestingnode or target node), the end node replies to the other end node with anacknowledgement message (conveyed over the vLDP session) indicating thatthe label mapping message was received. In such an embodiment, somereliability state may be required at the relay node (e.g., atransactional ID that identifies the particular label mapping messagebeing acknowledged). However, the window of opportunity for losing vLDPmessages is small, so in another embodiment, a normal LDP gracefulrestart procedure can be applied (as discussed below) instead ofimplementing end-to-end acknowledgements.

In the event the vLDP session goes down (e.g., a TCP connection fails orthe relay node fails), vLDP messages can no longer be exchanged betweenthe pair of edge LSRs. In such a scenario, the vLDP session can bere-established via another relay node (if available), using the samesession ID. For example, there could be an alternate path between therequesting node and the target node via a backup relay node (not shown),where the backup relay node (or one or more backup relay nodes) is anLDP neighbor of the requesting node and the target node.

In the event a TCP connection fails between the requesting node and thetarget node, the relay node coupled to the failed TCP connection willnotify the end node (e.g., requesting node or target node, depending onwhere the failure occurs) of the failure using a vLDP peer-downnotification. The notified end node (that receives the peer-downnotification) starts a local timer and will send a vinit message for thesame session ID and LDP ID via other alternate paths to reach the otherend node. For example, the requesting node can send a vinit message withthe same session ID to the target node via a backup relay node. If thenotified end node receives a responsive vinit message from the other endnode within the local timer expiry, the notified end node will continueto use the vLDP session (e.g., uses the same vLDP session ID). If thelocal timer has expired before the notified end node receives theresponsive vinit message, the vLDP session is considered torn down.

In the event that the relay node fails, it is possible that some vLDPmessages in transit may be lost. When this happens, the vLDP session istorn down and the end nodes can perform normal LDP graceful restartbehavior. For example, the LDP state (e.g., FEC state, LDP bindings,and/or mLDP forwarding state) at the end nodes is maintained after thevLDP session is town down and is recovered for use in a subsequent (new)vLDP session (e.g., the label mappings at the end nodes are synchronizedwith one another).

In one embodiment, a backup vLDP session could be established at a timebefore the primary vLDP session fails. For example, a backup vLDPsession can be established on an alternate ECMP (Equal Cost MultiPath)or LFA (Loop Free Alternate) path, if such a path is known. A backupvLDP session is further discussed below in connection with FIG. 6.

Finally, while a vLDP session could replace a targeted LDP session(e.g., in situations where a targeted LDP session cannot beestablished), a vLDP session could be established over a targeted LDPsession in one embodiment. Such an embodiment could be used to reducethe number of labels used during a targeted LDP session to reach thedestination node. Using the illustrated example in FIG. 3B (and for thisembodiment only, nodes 350(1), 355(1) and 355(2) have IP connectivitywith one another), a targeted LDP session can be established between therequesting node 350(1) and relay node 355(2), where a point-to-point(P2P) LSP is established between requesting node 350(1) and relay node355(2) using targeted LDP. In this embodiment, a vLDP session could alsobe established over the targeted LDP session, between requesting node350(1) and target node 350(2). When relay node 355(2) receives a packetfrom the target node 350(2) over the vLDP session, relay node 355(2)need only use the (single) label of the established P2P LSP to forwardthe packet over the P2P LSP to the requesting node 350(1), rather thanusing two labels to reach the destination (e.g., a label from node355(2) to 355(1), and another label from node 355(1) to 350(1)).

FIG. 5A is a flowchart illustrating operations of an example vLDPsession establishment process implemented by a vLDP logic module on arequesting node (or LSR) in a first network segment that has limitedrouting information. vLDP logic module is configured to cooperate withan LDP logic module also configured on the requesting node (e.g., useexisting mechanisms of LDP logic module, as discussed above) to performthe process illustrated in FIG. 5A.

The process illustrated in FIG. 5A starts at operation 505, where an IPunreachability detector of vLDP logic module determines an address of atarget node. As discussed above in connection with FIG. 2, IPunreachability detector uses a discovery mechanism to determine ordiscover the target node's address. The process continues to operation510, where the IP unreachability detector determines that the targetnode is IP unreachable (e.g., consult a BGP table and/or other routingtables at the requesting node to determine no route is known for thetarget node's address). In other words, IP unreachability detectordetects that a targeted LDP session cannot be established from therequesting node in the first network segment to an IP unreachable targetnode in a second network segment.

The process continues to operation 515, where vinit message generator ofvLDP logic module generates a vinit message. The vinit message includesa source address of the requesting node, a destination address of thetarget node, a session ID of the vLDP session being established, and theLDP ID of the requesting node. The process continues to operation 520,where vinit message generator transmits the vinit message toward thetarget node via an IP reachable relay node. As discussed above inconnection with FIG. 2, a discovery mechanism also exists to discover arelay node that reaches the target node (e.g., consult a BGP tableand/or other routing tables at the requesting node and determine adirectly connected IP reachable relay node that is the next hop nodetoward the target node). The vinit message is transmitted from a port ofthe requesting node directly connected to the relay node, where thevinit message is transmitted over a TCP connection coupling therequesting node and the relay node.

The process continues to operation 525, where vinit message processor ofthe requesting node detects whether a responsive vinit message isreceived on a port of the requesting node from the target node (via thedirectly connected relay node that reaches the target node). Theresponsive vinit message includes a same vLDP session ID of the(initial) vinit message that was sent to the target node and sourceaddress of the target node. The responsive vinit message also includesan LDP ID of the target node. If a responsive vinit message has not beenreceived, the process continues to operation 530, where vinit messageprocessor waits for the responsive vinit message from the target node.The process returns to operation 525 to check whether the responsivevinit message has been received. Once the responsive vinit message isreceived at the requesting node (over the TCP connection coupling therequesting node and the relay node), the process continues to operation535, where the vLDP session is established. The responsive vinitmessage, or portion thereof, can be directed internally to vinit messageprocessor of the requesting node. In one embodiment, vinit messageprocessor extracts a stack of one or more relay labels from theresponsive vinit message using a relay label extractor. In oneembodiment, vinit message processor also stores the stack of one or morerelay labels (e.g., locally at the requesting node). In one embodiment,vinit message processor also pushes an outer label on the stored relaylabel stack, where the outer label is an outgoing label is used by therequesting node to reach the relay node from which the responsive vinitmessage is received. In one embodiment, the (stored) relay label stackand outer label are also associated with the session ID of the vLDPsession and/or the LDP ID of the target node that are included in theresponsive vinit message. The process then ends.

FIG. 5B is a flowchart illustrating operations of an example vLDPsession establishment process implemented by a vLDP logic module on areceiving node (or LSR), such as a relay node located between networksegments or a target node located in the second network segment that haslimited routing information. vLDP logic module is configured tocooperate with an LDP logic module also configured on the receiving node(e.g., use existing mechanisms of LDP logic module, as discussed above)to perform the process illustrated in FIG. 5B.

The process illustrated in FIG. 5B starts at operation 540, where vinitmessage processor of vLDP logic module detects that a vinit message hasbeen received at a port of the receiving node over a TCP connection(which can be coupled to a requesting node or to a relay node). Thevinit message, or portion thereof, can be directed internally to vinitmessage processor. The process continues to operation 545, where vinitmessage processor determines whether the destination address of thevinit message is owned by the receiving node. If the receiving node doesnot own the destination address, the receiving node is a relay node andthe process continues to operation 550. At operation 550, the vinitmessage processor of the relay node inserts a relay label into the vinitmessage using a relay label insertor (such as by pushing the relay labelonto an existing label stack, if any, in the vinit message), whichproduces an updated vinit message. The process continues to operation555, where the vinit message processor of the relay node forwards theupdated vinit message toward the target node. For example, vinit messageprocessor can consult a BGP table and/or other routing tables at therelay node and determine an IP reachable relay node that is the next hopnode toward the target node, or can determine that the target nodeitself is the next hop node. The updated vinit message is transmittedfrom a port of the relay node directly connected to the next hop nodeover a TCP connection coupling the relay node and the next hop node(e.g., the target node or another relay node). The process then ends.

Returning to operation 545, if the receiving node owns the destinationaddress, the receiving node is a target node and the process continuesto operation 560. At operation 560, the vinit message processor of thetarget node extracts a stack of one or more relay labels from the vinitmessage using a relay label extractor. In one embodiment, vinit messageprocessor also stores the stack of one or more relay labels (e.g.,locally at the target node). In one embodiment, vinit message processoralso pushes an outer label on the stored relay label stack, where theouter label is an outgoing label is used by the target node to reach therelay node from which the responsive vinit message is received. In oneembodiment, the (stored) relay label stack and outer label are alsoassociated with the session ID of the vLDP session and/or the LDP ID ofthe requesting node that are included in the vinit message.

The process continues to operation 565, where vinit message generator ofthe target node generates a responsive vinit message. The responsivevinit message includes a source address of the target node, adestination address of the requesting node, and the same vLDP session IDthat was included in the received vinit message. The responsive vinitmessage also includes an LDP ID of the target node. The processcontinues to operation 570, where vinit message generator of the targetnode transmits the responsive vinit message towards the requesting nodevia the IP reachable relay node from which the initial vinit message isreceived. The responsive vinit message is transmitted from a port of thetarget node over a TCP connection coupling the target node and the relaynode. In one embodiment, vinit message generator imposes on theresponsive vinit message: the stack of relay labels of the (received)vinit message and an outgoing label that reaches the relay node fromwhich the (received) vinit message (of operation 540) was received. Insuch an embodiment, the responsive vinit message is label-switched backto the requesting node (without collecting a second stack of relaylabels). The process then ends.

FIG. 5C is a flowchart illustrating operations of an example vLDPmessage exchange process implemented by a vLDP logic module configuredon an end node (e.g., a requesting node or a target node), using a vLDPsession established between a requesting node and a target node. Theprocess illustrated in FIG. 5C is performed at vLDP logic module isconfigured to cooperate with an LDP logic module also configured on thesame end node (e.g., use existing mechanisms of LDP logic module, asdiscussed above) to perform the process illustrated in FIG. 5C.

The process illustrated in FIG. 5C starts at operation 575, where vLDPmessage generator of vLDP logic module generates a vLDP message. ThevLDP message includes a LDP ID of the destination end node, the sessionID that identifies the vLDP session over which the vLDP message is sent,and an LDP message. The process continues to operation 580, where vLDPmessage generator imposes the (stored) stack of relay label(s)associated with the session ID and/or the LDP ID onto the vLDP message.The (stored) stack of relay label(s) includes an outer label thatreaches the relay node directly connected to the end node implementingthe process illustrated in FIG. 5C. The process continues to operation585, where the vLDP message is label-switched to the destination endnode. For example, if the target node is sending a vLDP message to therequesting node, the target node will retrieve the relay labels (andouter label) associated with the session ID that identifies the vLDPsession established between the requesting node and the target nodeand/or with the LDP ID of the requesting node. The target node willimpose the relay labels on the vLDP message and label switch the vLDPmessage back to the requesting node. The process then ends.

FIG. 6 is a block diagram illustrating components of an example networkin which the present disclosure can be implemented. Two aggregationnetwork segments 610(1) and 610(N) are coupled to a core network segment620, which couple provider edge LSRs 630(1) and 630(2). Each networksegment includes a number of core LSRs 640 and are coupled by a numberof border LSRs 650. As illustrated, aggregation network segment 610(1)is coupled to core network segment 620 via border LSRs 650(1) and650(2), while aggregation network segment 610(N) is coupled to corenetwork segment 620 by border LSRs 650(3) and 650(4).

mLDP (multipoint LDP) node protection is implemented in FIG. 6, whereborder LSR 650(1) is a protected node 660. As implemented by mLDPprotocol logic (which can be included in LDP protocol logic implementedon a node), the protected node determines its upstream neighbor, coreLSR 640(2), which is the Point of Local Repair 675. The protected nodeinforms its downstream neighbor, core LSR 640(1), which is the MergePoint (MPT) 670, about the PLR. For example, the protected nodeadvertises the PLR's address to the MPT in an mLDP notification message.The MPT (traditionally) establishes a targeted LDP session with the PLRand registers its interest in receiving content (which would usually beforwarded by the protected node to the MPT via a particular multipointLSP) from the PLR in the event that the protected node fails. If theprotected node fails, content can be redirected around the failed nodefrom the PLR to the MPT. However, if the MPT and PLR do not have IPconnectivity with one another (e.g., the MPT and PLR are located indifferent network segments that have limited routing information, asdiscussed above), the MPT cannot establish a targeted LDP session withthe PLR and signal the MPT's interest to the PLR. Instead, the MPT canestablish a vLDP session with the PLR (as also discussed above), usingthe protected node as a relay node. The MPT can inform the PLR of theMPT's interest in receiving content of the particular multipoint LSP, inthe event that the protected node fails. In one embodiment, theparticular multipoint LSP is identified by an FEC, which can be includedin an FEC element of an mLDP message (e.g., an mLDP notification sent tothe PLR).

Additionally, mLDP protocol logic builds a multipoint LSP (such as theparticular multipoint LSP that will provide content to the MPT) fromprovider edge LSR 630(1) toward a root node (such as provider edge LSR360(2)), where the address of the root node is included in an FEC thatidentifies the multipoint LSP. The FEC is included in an FEC element ofan mLDP label mapping message. The mLDP label mapping message isforwarded to an intermediate node that is the next hop toward the rootnode. The intermediate node is expected to be able to look up the rootnode address in its routing tables in order to find a route toward theroot node on which to forward the mLDP label mapping message. However,if the root node is not IP reachable by the intermediate node (e.g., islocated in a different network segment that has limited routinginformation), the intermediate node cannot forward the mLDP labelmapping message (and thus cannot build the LSP) to the root node.

In one embodiment, a border LSR that recognizes the root node isunreachable by an intermediate node (such as by consulting BGP tablesand/or other routing tables) can create a new FEC element of the mLDPlabel mapping message, which is referred to as a recursive FEC element.The border LSR encapsulates the content of the original FEC element inthe recursive FEC element and adds the address of a temporary root node(such as another border LSR from which the original root node is IPreachable) to the recursive FEC element. An intermediate node thatreceives the mLDP label mapping message with the recursive FEC elementwill forward the mLDP label mapping message (and build the LSP) towardthe temporary root node address of the recursive FEC element, based onthe route to the temporary root node in its routing tables. Once themLDP label mapping message arrives at the temporary root node, thetemporary root node recognizes the FEC element of the mLDP label mappingmessage is actually a recursive FEC and removes the temporary root nodeaddress (which is owned by the temporary root node) to reveal theoriginal FEC element. The mLDP label mapping message can then beforwarded using the original FEC element toward the original root node.Accordingly, the recursive FEC element is used to forward an mLDP labelmapping message across parts of the network where there is no IPreachability to the original root node (e.g., across core networksegment 620).

As illustrated in FIG. 6, the mLDP label mapping message that includesan original FEC element would be forwarded hop by hop from provider edgeLSR 630(1) to core LSR 640(1) to border LSR 650(1). (Core LSR 640(1)would know about border LSR 650(1) via an existing discovery mechanism,as discussed above in connection with FIG. 2.) Border LSR 650(1)recognizes that this is a segmented network and that next hop core LSR640(2) does not have IP connectivity with the original root node (e.g.,provider edge LSR 630(2)). Border LSR 650(1) also recognizes that borderLSR 650(3) reaches the original root node (e.g., border LSR 650(3) isthe access point for the network segment in which the original root nodeis located). In response, border LSR 650(1) creates a recursive FECelement by encapsulating the original FEC element with the temporaryroot node address of border LSR 650(3), such as by adding a header orother portion to the original FEC element that includes the temporaryroot node address. Border LSR 650(1) then forwards the mLDP labelmapping message with the recursive FEC element to core LSR 640(2).

Core LSR 640(2) receives the mLDP label mapping message and views theFEC element included in the mLDP label mapping message as a normal FECelement, where border LSR 650(3) is identified as the root node. CoreLSR 640(2) performs a look up of the root node address (of border LSR650(3)) and forwards the mLDP label mapping message toward the rootnode. When border LSR 650(3) receives the mLDP label mapping message,border LSR 650(3) recognizes that the FEC element of the mLDP labelmapping message is a recursive FEC element, and removes the temporaryroot node address from the FEC element, such as by stripping off theheader or other portion from the recursive FEC element to reveal theoriginal FEC element. Border LSR 650(3) can then forward the mLDP labelmapping message based on the original FEC element.

In this embodiment using recursive FEC, the LSP is identified at MPT 670(or core LSR 640(2)) using the recursive FEC, while the LSP isidentified at PLR 675 (or core LSR 640(1)) using the original FEC. Ifnode protection is applied to border LSR 650(1), MPT 670 registers itsnode protection interest with PLR 675 using the original FEC. Since thePLR is only aware of the recursive FEC (and cannot view the original FECencapsulated within the recursive FEC), the PLR does not know to whichLSP the MPT wishes to apply node protection. In such a scenario, the PLRwould not be able to implement node protection for the particular LSPfrom which the MPT wishes to receive content.

Instead, when border LSR 650(1) (as protected node 660) creates a newrecursive FEC for the particular LSP, the protected node also providesthe recursive FEC to the MPT (such as in an mLDP notification messagesent to the MPT, which may also be the same mLDP notification messagethat includes the PLR's address). The MPT then uses the recursive FECfor the particular LSP when registering its node protection interestwith the PLR. The PLR uses the recursive FEC to identify the particularLSP that the MPT is interested in, and will forward content of theparticular LSP to the MPT in the event the protected node fails.

Content of the particular LSP can be redirected around the protectednode via a backup stitched point-to-point (P2P) LSP established betweenPLR and MPT. The MPT can determine that another border LSR 650(2) isconnected to PLR (e.g., by consulting a BGP table or the address ofborder LSR 650(2) may be manually configured at MPT), which can serve asa backup node 665 for the protected node. The MPT (which has receivedPLR's address from the protected node) can establish a backup vLDPsession with the PLR via border LSR 650(2) as a relay node. A backupstitched P2P LSP can also be established from the PLR to the MPT (e.g.,exchanging label mapping messages over the vLDP session), using thestack of labels collected by a vinit message sent from the PLR to theMPT and an outer label that the PLR uses to reach the backup node. Inthe event the protected node fails, the MPT can send content of theparticular LSP over the backup stitched P2P LSP from the MPT to the PLR(e g , impose the relay label stack and outer label on content of theparticular LSP at the MPT and label-switch the content to the PLR).

FIGS. 7A and 7B are flowcharts illustrating operations of an examplemLDP node protection process implementing the present disclosure. Theprocess illustrated in FIGS. 7A and 7B can be implemented in a networkwhere a border LSR is a protected node in an mLDP node protectionscenario.

The process illustrated in FIG. 7A starts at operation 705, where theprotected node determines the address of its upstream node neighbor,which is the Point of Local Repair (PLR). The process continues tooperation 710, where the protected node includes the PLR's address in anLDP notification message. The protected node also includes the recursiveFEC of the multipoint (MP) LSP in the LDP notification message, if arecursive FEC was created by the protected node. The process continuesto operation 715, where the protected node sends the LDP notificationmessage to its downstream node neighbor, which is the Merge Point (MPT).

The process continues to operation 720, where the MPT determines thatthe PLR is unreachable (e.g., there is no IP connectivity between theMPT and the PLR), as discussed above. The process continues to operation725, where the MPT establishes a vLDP session with the PLR over aprimary relay node, as further discussed above in reference to FIGS. 5Aand 5B (where MPT acts as the requesting node and PLR acts as the targetnode, and a vinit message is sent toward the PLR via the primary relaynode). The process continues to operation 730, where the MPT indicatesthe MPT's node protection interest (which is associated with aparticular MP LSP) to the PLR via the vLDP session. The processcontinues to operation 735, where the MPT and PLR establish a backupstitched P2P LSP to protect the protected node, as further discussedbelow in reference to FIG. 7B. The process then ends.

The process illustrated in 7B begins at operation 750, where the MPTestablishes a backup vLDP session with the PLR over a backup relay node,as further discussed above in connection with FIGS. 5A and 5B (where MPTacts as requesting node and PLR acts as target node, and a vinit messageis sent toward the PLR via the backup relay node). The process continuesto operation 755, where the MPT and PLR exchange label bindings over thebackup vLDP session, as further discussed above in connection with FIG.5C. The process continues to operation 760, where the MPT and PLR builda backup stitched P2P LSP over the backup relay node, which is used inthe event when the primary relay node (or a link to the primary relaynode) fails. The process then ends.

FIG. 8 is a block diagram illustrating components of an example networkdevice 800 configured as a routing device (e.g., label switching routingelements 120(1)-(N) of FIG. 1). In this depiction, network device 800includes a number of line cards (line cards 802(1)-802(N)) that arecommunicatively coupled to a control module 810 (which can include aforwarding engine, not shown) and a route processor 820 via a data bus830 and a result bus 840. Line cards 802(1)-(N) include a number of portprocessors 850(1,1)-850(N,N) which are controlled by port processorcontrollers 860(1)-860(N). It will also be noted that control module 810and route processor 820 are not only coupled to one another via data bus830 and result bus 840, but are also communicatively coupled to oneanother by a communications link 870. It is noted that in alternativeembodiments, each line card can include its own forwarding engine.

When a message (e.g., a vinit message and/or a vLDP message) is receivedby a network device such as network device 800 (e.g., received by alabel switching routing element 120), the message is identified andanalyzed by the network device in the following manner. Upon receipt, amessage (or some or all of its control information) is sent from one ofthe port processors 850(1,1)-850(N,N) at which the message was receivedto one or more of those devices coupled to data bus 830 (e.g., others ofport processors 850(1,1)-850(N,N), a forwarding engine, and/or routeprocessor 820). Handling of the message can be determined, for example,by a forwarding engine. For example, a forwarding engine may determinethat the message should be forwarded to one or more of port processors850(1,1)-850(N,N). This can be accomplished by indicating tocorresponding one(s) of port processor controllers 860(1)-860(N) thatthe copy of the message held in the given one(s) of port processors850(1,1)-850(N,N) should be forwarded to the appropriate one of portprocessors 850(1,1)-850(N,N).

Network device 800 can implement LDP logic module 140 and/or vLDP logicmodule 150 in control module 810 (as shown), or in one of port processorcontrollers 860(1)-860(N) and/or in route processor 820 in order toimplement the present disclosure. Although not shown, network device 800can also implement a routing protocol module and/or network reachabilityprotocol module in control module 810, in one of port processorcontrollers 860(1)-860(N), and/or in route processor 820 (not shown).

An incoming message (e.g., a vinit message or a vLDP message), orinformation thereof, can be provided to vLDP logic module 150 via aforwarding engine or port processor of a line card coupled to a portthat received the incoming message. vLDP logic module 150 is alsoconfigured to communicate with LDP logic module 140 and to generate (incooperation with LDP logic module 140) an outgoing message (e.g., avinit message or a vLDP message), as described above in connection withFIGS. 5A-5C. The outgoing message can be provided by vLDP logic module150 to a forwarding engine, which can determine that the outgoingmessage should be forwarded to one or more of port processors850(1,1)-850(N,N) that are configured to transmit the outgoing message(e.g., transmitted to another network device) toward the outgoingmessage's destination.

FIG. 9 is a block diagram illustrating components of an example networkdevice 900, in which the network device is configured as a routingdevice (e.g., label switching routing elements 120(1)-(N) of FIG. 1). Asillustrated, network device 900 includes one or more processors 902(e.g., microprocessors, PLDs (Programmable Logic Devices), or ASICs(Application Specific Integrated Circuits)) configured to executeprogram instructions stored in memories 906 and/or 908, which arecomputer readable storage media. Memories 906 and 908 can includevarious types of RAM (Random Access Memory), ROM (Read Only Memory),Flash memory, MEMS (Micro Electro-Mechanical Systems) memory, and thelike. Network device 900 also includes one or more ports 904 (e.g., oneor more hardware ports or other network interfaces that can be linked toother network devices, hosts, servers, storage devices, or the like).Processor 902, port 904, and memories 906 and 908 are coupled to sendand receive data and control signals by one or more buses or otherinterconnects.

In this example, program instructions executable to implement LDP logicmodule 140 and/or vLDP logic module 150 are stored in memory 906.Program instructions executable to implement a routing protocol moduleand/or a network reachability protocol module can also be stored inmemory 906 and/or in memory 908 (not shown). Routing information andnetwork reachability information can be stored in one or more routingtables and/or forwarding tables, including a label forwardinginformation base (LFIB) configured in memory 906 or 908 (not shown).

Message 910 (e.g., a vinit message or a vLDP message) is stored inmemory 908. In one embodiment, message 910, or information thereof, canbe received from port 904 (e.g., received from another network devicecoupled to port 904), and can be stored in memory 908 before beingprovided to vLDP logic module 150. vLDP logic module 150 includesfunctionality needed to establish a virtual LDP session by exchangingone or more messages (e.g., sending a vinit message in response to areceived vinit message).

vLDP logic module 150 also includes functionality needed to communicatewith LDP logic module 140 and to cooperatively generate (with LDP logicmodule 140) an outgoing message 910 (e.g., a vinit message or a vLDPmessage), as described above in connection with FIG. 9. In oneembodiment, outgoing message 910 can be generated and stored in memory908 before being transmitted via port 904 (e.g., transmitted to anothernetwork device in the network that is coupled to port 904).

Although the present disclosure has been described with respect tospecific embodiments thereof, various changes and modifications may besuggested to one skilled in the art. It is intended such changes andmodifications fall within the scope of the appended claims.

What is claimed is:
 1. A method comprising: a requesting node sending avirtual Label Distribution Protocol initialization (vinit) messagetowards a target node, wherein the vinit message comprises: a request toestablish a virtual Label Distribution Protocol (vLDP) session betweenthe requesting node the target node; an address for the requesting nodeand an address for the target node, and; a vLDP session ID; therequesting node receiving another vinit message from another node aftersending the vinit message, wherein the other vinit message comprises thevLDP session ID.
 2. The method of claim 1 further comprising: therequesting node extracting a stack of one or more labels from the othervinit message; the requesting node storing the extracted stack inmemory; the requesting node adding another label to the stored stack tocreate a modified stack in memory, wherein the other label is used bythe requesting node to reach the other node.
 3. The method of claim 2wherein the one or more relay labels were provided by one or more relaynodes and define an LDP path between the target node and the requestingnode for messages transmitted over the vLDP session, and wherein the oneor more relay nodes are located between the requesting node and thetarget node.
 4. The method of claim 2 further comprising mapping thevLDP session ID with the modified stack in memory.
 5. The method ofclaim 3 further comprising: the requesting node generating a message;the requesting node attaching a copy of the modified stack to themessage; the requesting node forwarding the message with attachedmodified stack to the other node.
 6. The method of claim 1 wherein therequesting and target nodes are contained in separate network segments.7. The method of claim 1 further comprising: the requesting nodedetermining the target node is unreachable; the requesting nodegenerating the vinit message in response to determining the target nodeis unreachable.
 8. A node comprising: one or more processors; and amemory to store instructions executable by the one or more processors,to perform operations comprising: sending a virtual Label DistributionProtocol initialization (vinit) message towards a target node, whereinthe vinit message comprises: a request to establish a virtual LabelDistribution Protocol (vLDP) session between the node the target node;an address for the node and an address for the target node, and; a vLDPsession ID; receiving another vinit message from another node aftersending the vinit message, wherein the other vinit message comprises thevLDP session ID.
 9. The node of claim 8 wherein the operations furthercomprise: extracting a stack of one or more labels from the other vinitmessage; storing the extracted stack in memory; adding another label tothe stored stack to create a modified stack in memory, wherein the otherlabel is used by the requesting node to reach the other node.
 10. Thenode of claim 9 wherein the one or more relay labels were provided byone or more relay nodes and define an LDP path between the target nodeand the node for messages transmitted over the vLDP session, and whereinthe one or more relay nodes are located between the node and the targetnode.
 11. The node of claim 10 wherein the operations further comprisemapping the vLDP session ID with the modified stack in memory.
 12. Thenode of claim 11 wherein the operations further comprise generating amessage; attaching a copy of the modified stack to the message;forwarding the message with attached modified stack to the other node.13. The node of claim 8 wherein the operations further comprise:determining the target node is unreachable; generating the vinit messagein response to determining the target node is unreachable.
 14. One ormore computer-readable storage media storing instructions that, whenexecuted by one or more processors of a node, cause the one or moreprocessors to perform operations comprising: sending a virtual LabelDistribution Protocol initialization (vinit) message towards a targetnode, wherein the vinit message comprises: a request to establish avirtual Label Distribution Protocol (vLDP) session between the node thetarget node; an address for the node and an address for the target node,and; a vLDP session ID; receiving another vinit message from anothernode after sending the vinit message, wherein the other vinit messagecomprises the vLDP session ID.
 15. The one or more computer-readablestorage media of claim 14 wherein the operations further comprise:extracting a stack of one or more labels from the other vinit message;storing the extracted stack in memory; adding another label to thestored stack to create a modified stack in memory, wherein the otherlabel is used by the requesting node to reach the other node.
 16. Theone or more computer-readable storage media of claim 15 wherein theoperations further comprise mapping the vLDP session ID with themodified stack in memory.
 17. The one or more computer-readable storagemedia of claim 15 wherein the operations further comprise: generating amessage; attaching a copy of the modified stack to the message;forwarding the message with attached modified stack to the other node.18. The one or more computer-readable storage media of claim 14 whereinthe operations further comprise: determining the target node isunreachable; generating the vinit message in response to determining thetarget node is unreachable.
 19. The one or more computer-readablestorage media of claim 15 wherein the one or more relay labels wereprovided by one or more relay nodes and define an LDP path between thetarget node and the node for messages transmitted over the vLDP session,and wherein the one or more relay nodes are located between the node andthe target node.
 20. The one or more computer-readable storage media ofclaim 14 wherein the node and target node are contained in separatenetwork segments.